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Methode de decouverte d'un reseau domesfique et appareil 

implementant la meihode. 

Uinterop6rabilit6 audio et video domestique (HAVi pour « Home ' 
5 Audio Video interoperability » en anglais) est une specification developpee 
par des entreprises d'6lectronique grand public qui permet Pinterconnexion 
d'appareils audio et video dans un environ nement domestique bas6 sur un 
reseau utilisant la technologie des bus IEEE 1394. La version courante 
(version 1.1, disponible aupres de HAVi, Inc. 2694 Bishop Drive, Suite 275 
10 San Ramon, CA 94583, USA) n'est pas pr6vue pour fonctionner sur des 
r6seaux bases sur d'autres technologies que les bus IEEE 1394, dont la 
reference est le standard IEEE 1394-2000. ' 

En T6tat actuei du marche des appareils domestiques, il apparait que 
15 les reseaux qui sont dSveloppes dans le cadre domestique sont 
generalement hSterogenes et font intervenir des technologies diverses autres 
que IEEE 1394. On peut citer, par exemple, I'importance prise par les 
reseaux respectant le protocole Internet (IP pour « Internet Protocol » en 
anglais) dont on peut trouver une reference sous la forme d'une requite pour 
20 commentaires (RFC pour « request for comment » en anglais) sous le -S 
numero RFC 791, ces requites 6tant maintenues par le groupe de travail - 
d'ingenierie Internet (IETF pour « Internet Engineering Task Force » en > . 
anglais). La specification HAVi ayant ete congue dans le cadre d'une 
application sur un bus 1394, son utilisation sur un reseau d'une autre 
25 technologie pose le probleme de son adaptation & cette autre technologie. 

L'invention concerne rinterop6rabilit6 audio et video sur des reseaux 
base sur d'autres technologies de reseau que le bus 1394. 

30 L'invention concerne plus particulierement une m6thode de 

decouverte, par un appareil connectable a un reseau de communication, des 
autres appareils connectes qui comporte une 6tape de connexion de 
I'appa.reil audit reseau, une etape d'envoi d'un message d'annonce 
contenant des informations d'auto description decrivant I'appareil a 

35 destination de tous les autres appareils connectes a ce reseau, une etape 
d'envoi d'un message de demande d'informations d'auto description a tous 
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les autres appareils connectes a ce reseau et une etape de reception d'un 
message de reponse de chacun des autres appareils du reseau contenant 
les informations d'auto description de cet autre appareil. 

Selon un mode particulier de realisation de I'invention le message de 
demande et le message d'annonce sont confondus. 

Selon un mode particulier de realisation de I'invention les 
informations d'auto description decrivant un appareil contiennent I'adresse 
sur le reseau de I'appareil. 

Selon un mode particulier de realisation de I'invention les 

informations d'auto description decrivant un appareil contiennent un 
identificateur global unique, different de I'adresse, identifiant I'appareil sur le 
reseau. 

Selon un mode particulier de realisation de I'invention les 

informations d'auto description decrivant un appareil contiennent les 
caracteristiques d'un module logiciel permettant de controler cet appareil. 

Selon un mode particulier de realisation de I'invention le message 
d'annonce est envoye en diffusion generate sur le reseau. 

* 

Selon un mode particulier de realisation de I'invention ie message 
d'annonce est envoye en diffusion multipoint sur une adresse de diffusion 
multipoint predefinie a laquelle les autres appareils doivent etre abonnes. 

L'invention concerne egalement un appareil connectable a un reseau 
qui possede des moyens d'envoyer un message d'annonce, contenant des 
informations d'auto description le decrivant, a tous les autres appareils du 
reseau, des moyens d'envoi d'un message de demande d'informations 
d'auto description a tous les autres appareils du reseau et des moyens de 
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reception des messages de reponses contenant des informations decrivant 
chacun des autres appareils du reseau. 

Selon un mode particulier de realisation de I'invention I'appareil 
5 comporte des moyens permettant de g6nerer un identificateur global unique, 
different de I'adresse de I'appareil, sur le reseau. 

Selon un mode particulier de realisation de Tinvention I'appareil 
comporte des moyens d'envoi du message d'annonce en diffusion gen6rale 
10 surler6seau. 

Selon un mode particulier de realisation de I'invention I'appareil 
comporte des moyens d'envoi du message d'annonce en diffusion multipoint 
sur une adresse de diffusion multipoint predefinie £ laquelle les autres 
1 5 appareils doivent etre abonnes. 

• * 

L'invention sera mieux comprise, et d'autres particularites et ;$ 
avantages apparaTtront a la lecture de la description qui va suivre, la 
description faisant reference aux dessins annexes parmi lesquels : 

20 

La figure 1 represente I'architecture de la pile HAVi telle que definie 
sur un reseau 1 394. 

La figure 2 represente I'architecture de la pile HAVi telle 
qu'impl6mentee dans I'exemple de realisation de I'invention. 
25 , La figure 3 represente le format du paquet d'annonce tel que defini 

dans I'exemple de realisation de Tinvention. 

La figure 4 represente le format du paquet de demande des SDD tel 
que defini dans I'exemple de realisation de ['invention. 

La figure 5 represente les etapes de la phase de decouverte du 
30 reseau dans le cadre de I'exemple de realisation de I'invention. 

La figure 6 represente I'architecture materielle d'un appareil 
supportant HAVi sur un reseau IP. 

L'exemple de realisation de I'invention qui va suivre se place dans le 
35 contexte de I'adaptation de HAVi a un reseau de type IP, mais il est evident 
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que rinvention n'est pas limitee a ce type de reseau et qu'elle peut etre 
utilisee pour adapter HAVi a tout autre type de reseau. [.'invention peut aussi 
etre utilisee dans le cadre d'une specification autre que HAVi, des que Ton va 
rechercher a decouvrir les appareils connectes a un reseau. 

La figure 1 represente ('architecture de la pile HAVi telle qu'elle est 
definie dans la specification HAVi sur un r6seau constitue de bus 1394 La 
pile HAVi est programmable en JAVA via IAPI (« Application programming 
interface)) en anglais) 1.1. La pile d'un appareil peut comprendre des 
modules de controle de I'appareil (DCM pour « Device Control Module » en 
anglais) ou des modules de contr6le de fonctionnaiites de I'appareil (FCM 
pour « Function Control Module)) en anglais) 1.7. La pile peut aussi 
comprendre des modules natifs 1.8. Une base de registres 1.2 (« Registry » 
en anglais) maintient une base de tous les appareils sur le reseau Un 
gestionnaire d'evenements 1.3 (« Event Manager)) en anglais) est 
responsable de la diffusion sur le reseau des evenements resultant d'un 
changement d'etat d'un appareil. Un gestionnaire de ressources 14 
(« Resource Manager ») permet le partage de ressources et la planification 
d'actions. Un gestionnaire de module de contrfile d'appareil 1.5 (« Device 
Control Module Manager » en anglais) permet d'installer et de retirer des 
modules permettant le contrdle d'autres appareils sur le reseau Un 
gestionnaire de flux 1 .6 (« Stream Manager » en anglais) permet de gerer les 
flux de transfert en temps reel des contenus audio et video sur le reseau Un 
systeme de messages (« Messaging System)) en anglais) 19 est 
responsable du passage de messages entre les differents composants du 
systeme. Un module d'adaptation a la couche de transport 1.10 (TAM pour 
« Transport Adaptation Module » en anglais) permet I'assemblage et la 
fragmentation des messages HAVi. Le gestionnaire du support de 
transmission 1.11 (CMM pour « Communication Media Manager » en 
angla.s) permet aux autres elements du systeme d'utiliser directement le 
support de transmission sans passer par le gestionnaire de messages. C'est 
necessaire. en particulier pour pouvoir implementer des modules de contrdle 
d'appareils non HAVi ou le controle repose sur un protocole proprietaire Le 
gestionnaire de flux, le TAM ou le CMM dialoguent avec les pilotes du reseau 
35 1.12, en I'occurrence 1394. 



20 



25 



30 
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La figure 2 represente ['architecture de la pile HAVi dans le cadre de 
i'exemple de realisation de ['invention. On retrouve les memes elements que 
dans la figure precedente a I'exception du module d'adaptation S la couche 
de transport 2.10, lei nous retrouvons le protocole TCP qui tient lieu de TAM. 
5 Le gestionnaire de support de transmission doit etre adapte a IP et non plus 
a 1394. Nous avons done un CMMIP 2.11. Ces modules interagissent avec 
la couche IP 2.12. Le gestionnaire de flux quant a lui va interagir avec la 
couche 802.1 p/Q 2.13 apportant la quality de service sur IP pour I'Schange 
deflux. 

10 

La specification HAVi dSfinit un identificateur unique sur le r§seau 
pour un composant logiciel, cet identificateur est appele le SEID pour 
« Software Element Identifier » en anglais. Cet identificateur est code sur 80 
bits et est compose de deux elements distincts, un premier identificateur 

15 correspondant a un identificateur unique de I'appareil hebergeant le 
composant logiciel sur le reseau. Cet identificateur est sur 64 bits et est 
appele le GUID pour « Global Unique Identifier » en anglais. Ce GUID est ^ 
defini par la norme IEEE 1394 pour identifier de maniere unique les appareils 
1394, e'est l'EUl-64 du composant 1394 stock6 dans la memoire morte de -jjjj 

20 tout appareil 1394. Rappelons qu'un EUl-64, tel que d§fini par HEEE dans $ 
son document « Guidelines for 64-bit Global Identifier (EUl-64™) 
Registration Authority », est compose d'un identifiant d^ntreprise de 24 bits ;;| 
suivi d'une extension de 40 bits. ^ 

25 Le second element composant ce SEID est un identificateur de 16 

bits permettant d'identifier le composant au sein de Tappareil qui ThSberge. 
Le fait de concatener un identificateur unique pour I'appareil sur le reseau et 
un identificateur du composant sur I'appareil permet done d'identifier de 
maniere unique tout composant logiciel au sein du reseau HAVi. 

30 

Mais il n'existe pas d'identificateur equivalent sur 64 bits sur un 
reseau IP. Sur ce r§seau, seuls existent les adresses IP de 32 bits en IP 
version 4 et 128 bits en IP version 6, voire les adresses MAC de 48 bits 
lorsque le reseau est un r6seau Ethernet. Une premiere idee est de 
35 construire le SEID en concatenant I'identificateur naturel du reseau sur lequel 
on se trouve avec un identificateur local a Tappareil completant celui-ci pour 
construire un SEID de 80 bits. En fait cette solution ne fonctionne pas dans le 
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cas oil un reseau heterogene connecterait, par exemple, un bus base sur du 
1394 et un autre sur IP. Dans ce cas, la coexistence de SEID construit sur la 
base d'un GUID de 64 bits et d'un identifiant local sur 16 bits avec d'autres 
construits, par exemple, sur la base d'une adresse IP de 32 bits et d'un 
identifiant local de 48 bits, peut mener a la non-unicite des identificateurs. En 
effet, un SEID de 0xA9FE6410000000123456 correspondant a une adresse 
IP de 169.254.100.16 et un identificateur local de 0x000000123456 peut 
entrer en collision avec un SEID compose d'un GUID 
de0xA9FE641 00000001 2 et un identificateur local de 0x3456. Done, quel 
que soit le type de reseau sur lequel on veut gerer HAVi, il convient de 
garder la structure du SEID en un identificateur, le GUID. sur 64 bits et un 
identificateur local sur 1 6 bits. 

II faut done trouver le moyen de creer des GUID sur le reseau vise 
qui n'interferent pas avec les GUID standard sur, 1394, done avec les EUI-64 
de I'lEEE. Ces EUI-64 sont la concatenation d'un identificateur d'entreprise 
sur 24 bits identifiant I'entreprise a I'origine de I'appareil et d'une extension 
de 40 bits geree par I'entreprise a I'origine du EUI-64 qui est responsable de 
son unicite dans I'ensemble des identificateurs dont elle est a I'origine. Les 
identificateurs d'entreprise etant geres de maniere centralisee par I'autorite 
d'enregistrement de I'lEEE. Un premier moyen de construire un tel GUID sur 
un reseau IP version 4 est de prendre OxFFFFFFFE concatene avec 
I'adresse IP en question sur 32 bits. Comme la valeur OxFFFFFF ne doit pas 
etre allouee par I'lEEE comme identificateur d'entreprise, on est certain que 
cette methode de construction du GUID produira des identificateurs qui ne 
vont pas entrer en collision avec les GUID formes d'un EUI-64. 

Une autre maniere de faire est d'utiliser la methode preconisee par 
I'lEEE pour la construction d'un EUI-64 par extension d'une adresse MAC de 
48 bits, e'est a dire de choisir une construction de la forme 
OxccccccFFFFeeeeee ou Oxcccccc represents la partie identifiant I'entreprise 
dans I'adresse MAC et Oxeeeeee I'extension dans I'adresse MAC. Dans ce 
cas, la non-collision avec des EUI-64 est assure par le fait que I'lEEE 
restreint I'attribution des extensions de 40 bits qui ne doivent pas commencer 
par OxFFFFFF, ni par OxFFFFFE, qui sont respectivement reserves comme 
marque d'une extension d'une adresse MAC-48 et d'un EUI-48. 
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Le tableau suivant recapitule les differents formats d'adresses ou 
d'identificateurs dont il est fait etat dans les paragraphes pr£c6dents. 



Adresse MAC-48 


{ 

entreprisejd 24 bits 
extension 24 bits 


EUI-48 


entreprisejd 24 bits 
extension 24 bits 


EUl-64 


entreprisejd 24 bits 

* 

extension 40 bits 


SEID 


GUID 80 bits 
Localjd 1 6 bits 



5 Dans le cas du reseau IP version 6, le probleme est un peu different 

En effet, cette version de IP preconise des adresses sur 128 bits. Les 
adresses IP version 6 sont composees de deux parties de 64 bits, le prefixe 
et I'identificateur d'interface. Ce dernier est congu pour correspondre a un 
EUl-64 a la difference du « u/l » bit dans I'identificateur d'entreprise. Mais 

10 cette difference ne remet pas en cause Xunicite de l'EUI-64. On peut done 
directement prendre les 64 derniers bits de Tadresse IP version 6 pour 
constituer le GUID de I'appareil HAVi. 

* * 

■ / 

Dans le cas d'un appareil bi compatible IP version 4 et IP version 6, 
15 nous prendrons I'identificateur d6fini par Tadresse IP version 6 de I'appareil. 
Pour un appareil demarrant sur le reseau en suivant IP version 4 et devenant 
par la suite compatible version 6, il sera considere que I'appareil est 
deconnecte et reconnects, .il lui sera done attribue un identificateur issu de 
son adresse version 6. 

20 
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Quand un appareil HAVi se connecte au reseau, il entame une 
phase de decouverte du reseau lui permettant de connaTtre les autres 
appareils disponibles sur ce reseau. Dans le cas classique ou le reseau 
sous-jacent est un bus 1394, la phase de reinitialisation du bus entraTnee par 
le branchement d'un nouvel appareil, se termine par I'obtention par chaque 
appareil de la liste des adresses sur le bus de chacun des autres appareils 
connectes au bus. Ensuite, le nouvel appareil peut interroger chaque 
appareil du reseau de facon a lire dans sa memoire morte les donnees 
d'auto description de I'appareil (SDD pour « Self Describing Device »). En 
effet la specification HAVi impose que chaque appareil possede de telles 
donnees adressables en suivant la norme IEEE 1212. 

Le probleme se pose done de transposer cette phase de decouverte 
sur un reseau autre qu'un bus 1394. D'une part nous n'avons pas de 
mecanisme naturel permettant a un appareil du reseau de recuperer la liste 
des adresses de tous les appareils connectes au reseau. D'autre part, il n'est 
generalement pas possible d'aller lire dans la memoire d'un appareil distant 
comme ceia se fait si Ton suit la norme IEEE 1212. Le reseau IP, par contre, 
possede un mecanisme de diffusion generate (« broadcast » en anglais) qui 
permet d'envoyer un message sur le reseau sans destinataire precis, chaque 
appareil connecte recevant ledit message. II est done possible que chaque 
appareil se connectant au reseau envoie un message en diffusion generale 
sur le reseau pour s'annoncer. 

II existe egalement un mecanisme de diffusion multipoint 
(« multicast » en anglais). Ce mecanisme definit des adresses de diffusions 
multipoint. Par ce mecanisme tout paquet emis vers cette adresse de 
diffusion multipoint est recu par tout appareil s'etant abonne a cette adresse 
de diffusion. II est done possible de definir une adresse connue de diffusion 
multipoint dediee a I'annonce sur le reseau des appareils HAVi. Chaque 
appareil se connectant au reseau s'annonce a cette adresse de diffusion 
multipoint et tous les autres appareils du reseau, abonnes a cette adresse 
dedi'6e, recevront I'annonce. 

Ce message peut de plus comporter les informations d'auto 
description contenues dans la SDD, de cette fagon chaque appareil du 
reseau peut mettre a jour ses tables avec ses informations comme s'il etait 
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alle les lire dans la m£moire de I'appareil. Ce message peut par exemple 
utiliser le protocole UDP au-dessus de IP. De cette fagon, nous beneficions 
de la detection d'erreur d'UDP. II est egalement possible de definir un port 
UDP dedte & HAVi. Un exemple de ces informations est donne figure 3. On y 
trouve : 

- Version de message HAVi : comme dans la specification HAVi 
1.1, il donne la version de systeme HAVi supporte par cet 
appareil. 

o Le premier octet est reserve et doit etre 0x00 
o Le second octet est le numero de version majeur 
o Le troisieme octet est le numero de version mineur 

Code operation : les valeurs sont 
o 0 : vivant 
o 1 : quittant 
o 2 : demande 
o 3 3 255 : reserve 

- Identificateur de mise a jour : un champ de 8 bits initialise a 0 
et increments & chaque fois qu'une valeur change dans le 
message. Ceci permet de savoir si un changement dans le 
message est apparu sans avoir a comparer toutes les valeurs. 

- Classe d'appareii : definit la classe de I'appareil, peut etre : 
o ObOOOO : reserve 

o 0b0001 : audio video de base (BAV pour. « Basic Audio 

Video » en anglais) 
o 0b0010 : audio video intermediate (IAV pour « Intermediate 
. . . Audio Video » en anglais) 

o 0b0011 : audio video complet (FAV pour « Full Audio 

Video » en anglais) 
o 0b0100 a 0b1111 : reserve 
• - DM : ce bit sp§cifie pour les appareils IAV si un gestionnaire 
de DCM est. implements, doit etre 3 0 pour un appareil BAV et 
& 1 pour les appareils FAV. 

- SM : ce bit specifie pour les appareils. IAV si un gestionnaire 
de flux est implements doit etre a 0 pour un appareil BAV et a 
1 pour les appareils FAV. 
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- RM : ce bit specifie pour les appareils IAV si un gestionnaire 
de ressources est implemente, doit etre a 0 pour un appareil 
BAV et a 1 pour les appareils FAV. 

- DC : ce bit specifie pour un appareil IAV si un controleur 
5 d'interactions dirigees par les donnees (DDI pour « Data 

Driven Interaction » en anglais) est implemente et pour un 
appareil FAV si un controleur DDI et une interface utilisateur 
de niveau 2 est implemente, doit etre a 0 dans le cas d'un 
appareil BAV. 

10 - DS : ce bit specifie le statut, actif ou inactif, de I'appareil, dans 

le cas d'appareil HAVi sur un reseau IP doit etre a 1, car le fait 
de s'annoncer sur le reseau signifie que I'appareil est actif. 

- Br : ce bit specifie si I'appareil est un pont. 

- GUID : I'identificateur global unique de I'appareil. 

15 " IPV4 adresse : I'adresse IP version 4 de I'appareil, doit etre & 

0 si celle-ci n'est pas definie. 

- IPV6 adresse : I'adresse IP version 6 de I'appareil, doit etre a 
0 si celle-ci n'est pas definie. 

- Vendeur ID: Identificateur du vendeur, defint de maniere 
20 globale et unique par I'lEEE, permet d'identifier le fabricant de 

I'appareil ; 

- Longueur vendeur : specifie la longueur du texte identifiant le 
vendeur, chaque caractere etant code en Unicode sur 16 bits. 

- Texte vendeur : chaTne de caracteres identifiant le vendeur, 
25 "mite a 50 caracteres par la specification HAVi. 

- Modele ID : identifie le modele d'appareil, defini par le 
fabricant de I'appareil. 

- Longueur modele : sp<§cifie la longueur du texte identifiant le 

modele, chaque caractere etant cod6 en Unicode sur 16 bits. 
30 - Texte modele : chaine de caractere identifiant le modele, limite 

a 50 caracteres par la specification HAVi. 

Les champs suivants sont disponibles uniquement pour les appareils 
BAV. Pour les appareils IAV, FAV et les appareils BAV qui ne fournissent 
35 pas ces informations et done pas d'unite de code DCM (« Device Control 
Module » en anglais), ces champs doivent exister et doivent etre mis a zero 
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jusqu'au champ « Tailie DCU URL » suivi de deux octets de complement a 
z6ro. 

- Tailie DCU : Tailie en octet de ('unite de code DCM transferee. 

- Espace DCU installee : tailie de m^moire requise pour 
5 Installation de I'unite sans compter I'espace de travail. 

- Espace de travail DCU : estimation de I'espace de travail 
requis par I'unite de code. 

- Tailie DCU URL : tailie en octet de I'adresse de la DCU 

- Donn6es URL : La chame de caracteres formant I'adresse ou 
10 trouver I'unite de code. 

On vient de voir comment un appareil se connectant au r6seau 
s'annon9ait aupres des autres appareils du reseau. II faut maintenant d§fihir 
comment cet appareil decouvre les autres appareils du r§seau. Pour ce faire, 

15 rappareil envoie une requete sur le r6seau. Cette requete peut §tre envoyee 
de la meme maniere que le message d'annonce decrit precedemment, c'est- . 
a-dire en diffusion generate ou en diffusion multipoint avec une adresse ^ 
connue. Cette adresse peut etre la meme que celle definie pour les 
messages d'annonce ou une autre sp6cifique pour ce message.' Chaque ^ 

20 appareil du r6seau qui regoit cette requete r§pond par un message diffuse en ^ 
unipoint (« unicast » en anglais). Ce message de reponse est done envoye & 
uniquement a Tappareil nouvellement connecte. Ce message de reponse doit $ 
contenir, comme Tannonce, les informations d'auto description normalement 
lues dans la SDD. Ce message de r6ponse peut prendre la meme forme que 

25 le message d'annonce avec le champ code operation mis a 0 pour « vivant ». 
Le format de la requete peut etre le format decrit a la figure 3 ou le champ 
« version de message HAVi » a le meme sens que dans I'annonce et ou le 
champ « code operation » est mis & 2. II est egalement envisageable que le 
message de reponse soit envoye directement en reponse au message 

30 d'annonce lors de la connexion du nouvel appareil au reseau. Dans ce cas 
les messages d'annonce et les messages de demande sont confondus. 

Les etapes de la phase de decouverte du reseau par un appareil se 
connectant sur ce r6seau sont recapitul6es figure 5. L'appareil se connecte 
35 au reseau, etape 5.1. Une fois connect, il envoie un message d'annonce 
contenant les informations d'auto. description le concernant a destination des 
appareils deja connectes sur le r6seau, etape 5.2. Ces informations d'auto 
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description sont le reflet des informations contenues dans la SDD des 
appareils 1394. Une fois que I'appareil s'est annonce sur le r6seau, il envoie 
une demande a destination de tous les autres appareils 5.3 par une diffusion 
generate ou une diffusion multipoint. Les autres appareils du reseau 
5 repondent & cette demande par renvoi de messages de reponse contenant 
les informations d'auto description les concernant a I'emetteur de la 
demande, etape 5.4. 

La specification HAVi pr6voit dans son architecture la presence d'un 

10 gestionnaire de support de communication, CMM pour « Communication 
Media Manager » en anglais. Le CMM est une entite dependante du reseau 
sous-jacent sur lequel est utilisee la specification HAVi. Ce gestionnaire 
apporte une interface vers le reseau de fagon a ce que des composants 
HAVi puisse interagir avec des appareils qui ne seraient pas totalement 

15 controlables par des ^changes de messages HAVi. En apportant une 
interface permettant Tutilisation directe du reseau sous-jacent on permet a un 
module HAVi de piloter tout appareil sur le reseau quel que soit son mode de 
fonctionnement et le protocole qu'il utilise, meme proprietaire. Une autre 
fonctionnaiite apportee par ce gestionnaire est de faire le lien entre les 

20 identificateurs uniques globaux des appareils HAVi sur le reseau (GUID) et 
leur adresse IP. Ce gestionnaire permet egalement d'implementer un 
mecanisme dedications sur le reseau. Gr3ce a ce mecanisme d'indications, 
il sera possible a un appareil de s'abonner ^ dies indications emises par un J * 
autre appareil sur le reseau. II va done pouvoir recevoir ces indications sous 

25 la forme de messages et gerer ces abonnements comme on va le voir dans 
la description des differentes fonctions constituant ce gestionnaire. 
L'abonnement a ces indications correspond au filtrage des paquets IP re<jus 
en fonction de leur origine et du protocole au dessus d'lP auquel ce paquet 
participe. Le gestionnaire adapte au reseau IP (CMMIP) est constitue des 

30 fonctions suivantes : 

Cmmip: :GetGuidList 

Status Cmmip::GetGuidList(out sequence<GUID> guidList) 

35 guidList est la liste des GUID de tous les appareils du reseau. 

Cette fonction permet de r6cup6rer la liste des GUID de tous les 
appareils HAVi du reseau. 
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Cmmip::Get1PAddress 

Status Cmmip::GetlPAdress( 
In GUID guid, 

5 ' Out sequence<lpAddress> ipAddressList) 



guid est le GUID de Pappareil HAVi. 

InAddressList est la liste des adresses IP de Pappareil dont le GUID 
est guid sur le rdseau. Un appareil pouvant avoir au plus une adresse IP 
10 version 4 et une adresse IP version 6. 

La fonction rend I'adresse IP de Pappareil identifie par son GUID. 
Cmmip::GetGuid 

15 Status Cmmip::GetGuid( • 

in lpAdress ipAdress, 
out GUID guid) 



ipAdress est I'adresse IP de Pappareil. 
20 guid est le GUID de Pappareil. . -|? 



Its 



La fonction rend le GUID de Pappareil identifie par son adresse IP. ^ 

-4 

■ \ 

* « 

Cmmip::Send 

25 Status Cmmip::Send( 

In Boolean useGuid, - 

In GUID guid, 

In IpAddress ipAdress, 

In uchar hopLimit, 
30 In uchar upperProtocol, 

In sequence<octet> data) 

useGuid est un booleen determinant si Pon utilise le GUID ou 
Padresse IP de Pappareil destination pour Pidentifier. 
35 guid est le GUID de Pappareil destination du message si useGuid est 

& vrai. - 
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ipAdress est I'adresse IP de I'appareil destination du message si 
useGuid est a faux. 

hopLimit est le nombre maximum de routeurs que peut traverser le 
message avant d'etre d6truit. 

5 upperProtocol est le code du protocole contenu dans la paquet IP 

par exemple le code pour UDP est 17. 

data represente la suite d'octets des donnees que Ton veut envoyer. 

Cette fonction permet d'envoyer un paquet IP a un appareil identifie 
10 soit par son GUID, soit par son adresse IP. 

Cmmip::EnrolIlndication 

Status Cmmip::Enrolllndication( 
in Boolean useGuid, 
15 inGUIDguid, 

in IpAdresse ipAdress, 
in OperationCode opCode, 
in uchar upperProtocol, 
out Boolean conflicts) 



0 
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useGuid est un booleen determinant si I'on utilise le GUID ou 
I'adresse IP de I'appareil destination pour I'identifier. 

guid est le GUID de I'appareil destination du message si useGuid est 

3 vrai. 

ipAdress est I'adresse IP de I'appareil destination du message si 
useGuid est & faux. 

opcode est le code operation fourni par I'appelant, c'est la valeur 
que le gestionnaire CMMIP va placer dans le champ « code operation » du 
message de notification qu'il enverra au client. 

upperProtocol est le protocole utilise par les indications que I'on 
souhaite recevoir. 

conflicts a la valeur vrai si cet abonnement (« enrollment » en 
anglais) entre en conflit avec un autre abonnement, faux sinon. 

Cette fonction permet a un client du gestionnaire CMMIP de s'abonner 
a des indications envoyees par un appareil sur le reseau en utilisant un 
protocole donne. Ce mecanisme permet de filtrer les paquets IP regus par 



\ 
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['interface de I'appareil en fonction de I'emetteur et du protocole utilise au- 
dessus de IP. Une adresse IP oil tous les bits sont a 1 (Oxffffffff en IP version 

4 ou o> crrrrrrrrrrrrrrrrrrrrrfrrrrrrrfrr en ip version 6) ou un guid ou tous les bits sont 

a 1 permet d'indiquer que Ton ne veut pas filtrer sur I'adresse de I'emetteur et 
5 que Ton veut recevoir tous les paquets regus ayant le bon protocole 
indifferemment de I'emetteur. Le gestionnaire CMMIP va stacker le SEID du 
client a Torigine du Cmmip::Enrolllndication qu'i! obtient du systeme de 
gestion des messages, ce qui va lui permettre ensuite quand il recevra un 
paquet IP correspondant & cet abonnement de iui renvoyer le paquet en 
10 question via un message grace a la fonction Cmmiplndication que nous 
verrons plus loin. Un m£me paquet IP peut correspondre a plusieurs 
abonnements et sera, dans ce cas, envoye & tous les modules abonnes. Le 
CMMIP est egalement responsable de la mise & jour des filtres lorsqu'un 
client est retire ou qu'un appareil est debranch6 du reseau. 

15 

Crnmip::Droplndication 

Status Cmmip::Droplndication( 
in Boolean useGuid, 
in GUID guid, 
20 in IpAdresse ipAdress, 

in uchar upperProtocol) 

useGuid est un booleen . determinant si Ton utilise le GUID ou .% 
l'adresse IP de I'appareil destination pour Tidentifier. 
25 guid est le GUID de I'appareil destination du message si useGuid est 

a vrai. 

ipAdress est I'adresse IP de I'appareil destination du message si 

useGuid est a faux. 

upperProtocol est le protocole utilise par les indications que Ton ne 

30 souhaite plus recevoir. 

Cette fonction permet a un client de se desabonner. 



<CIient>: :Cmmiplndication 

35 Status <Client>::Cmmiplndication( 

in Boolean useGuid, - 
in GUID guid, 
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n IpAdresse ipAdress, 
n uchar upperProtocol, 
n ushort dataSize, 
in sequence<octet> indicationData) 

useGuid est un booleen determinant si I'on utilise le QUID ou 
I'adresse IP de I'appareil destination pour ('identifier. 

guid est le QUID de I'appareil destination du message si useGuid est 

a vrai. 

ipAddress est I'adresse IP de I'appareil destination du message si 
useGuid est a faux. 

upperProtocol est le protocole utilise par ('indications que I'on 
souhaite envoyer. 

dataSize est la taille des donnees en octet que Ton compte envoyer 
indicationData, c'est une sequence d'octets representant les 
donnees effectives constituant Indication. 

Cette fonction est utilisee par le CMMIP pour envoyer a un client le 
message correspondant a un paquet IP repondant aux criteres d'un 
abonnement. Sur reception d'un paquet IP le CMMIP teste les differents 
abonnements en cours pour fes clients presents sur I'appareil. Si I'origine et 
le protocole du paquet IP correspondent aux criteres fixes par I'abonnement 
d'un client, le paquet lui est envoye par cette fonction. 

NewDevice 

void NewDevices(in sequ'ence<GUID> guidList) 

■ 

guidList est la liste des GUID des nouveaux appareils. 

* 

Cet evenement est genere par le CMMIP lorsqu'un ou plusieurs 
nouveaux appareils s'annoncent sur le reseau. Cet evenement n'est delivre 
que localement sur I'appareil hebergeant le CMMIP. en effetchaque appareil 
HAV, sur le reseau possedant son propre CMMIP, une diffusion generale de 
I'evenement n'est pas necessaire. 

GoneDevices 

void GoneDevices(in sequence<GUID> guidList) 
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guidList est la liste des GUID des appareiis ayant ete deconnectes. 

Get evenement est g6n<§r6 par !e CMMIP lorsqu'un ou plusieurs 
5 appareiis sont d6connectes du reseau. La deconnexion d'un appareil du 
reseau est detectee soit par renvoi d'un message signalant la deconnexion, 
soit par Texpiration de d§lais dans les tentatives de communication avec 
I'appareil en question ou lors de la phase de decouverte. Dans ce cas, le 
CMMIP envoie un ev6nement via le gestionnaire d'6venements signalant les 
10 GUID des appareiis ayant quitte le reseau. Cet evenement n'est delivre que 
localement sur I'appareil hebergeant le CMMIP, en effet chaque appareil 
HAVi sur le reseau possedant son propre CMMIP, une diffusion g6nerale de 
I'evenement n'est pas n§cessaire. 

15 ChangedDevices 

, void Changed Devices(in sequence<GUID> guidList) 

guidList est la liste des GUID des appareiis ayant change d'adresse,; ^ 

IP 

20 • % 

Cet evenement est genere par le CMMIP lorsqu'un ou plusieurs . g 
appareiis du reseau ont change d'adresse IP. Ce changement peut provenir 
de la detection d'une collision entre adresses IP ou autre. Le CMMIP envoie 
un evenement via le gestionnaire d'evenements signalant les GUID des 

25 appareiis ayant change d'adresse IP. Cet evenement n'est delivr6 que 
localement sur I'appareil hebergeant le CMMIP, en effet chaque appareil 
HAVi sur le reseau possedant son propre CMMIP, une diffusion generate de 
I'evenement n'est pas n6cessaire. Les clients qui le dSsirent peuvent, sur . 
reception de cet evenement, demander via la fonction Cmmip::GetlpAddress 

30 la nouvelle adresse du ou des appareiis en question. 

GuidListReady 

, void GuidListReady( . 

in sequence<GUID> guidList, 
35 in sequence<GUID> goneDevices, 

in sequence<GUID> newDevices, 
in sequence<GUID> ChangedDevices) 
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guidList est la liste des QUID de tous les appareils HAVi connectes 
au reseau. 

goneDevices est la liste, eventuellement vide, des GUID des 
appareils disparus du reseau lors de la reconfiguration. 

newDevices est la liste, eventuellement vide, des GUID des 
appareils apparus sur le reseau lors de la reconfiguration. 

changed Devices est la liste, eventuellement vide, des GUID des 
appareils ayant change d'adresse IP lors de la reconfiguration. 

Cet evenement est genere par le CMMIP quand la liste des GUID 
des appareils du reseau est disponible. En effet, lors d'une reconfiguration du 
reseau, cette liste n'est plus disponible via la fonction Cmmip::GetGuidList le 
temps que le CMMIP acheve la phase de decouverte du reseau 
nouvellement reconfigure. Cet evenement est un evenement local a 
I'appareil. 

ProxyGuidCreated 

void ProxyGuidCreated( 
in GUID proxyGuid, 

in sequenced pAddress> ipAddressList) 

proxyGuid est le GUID cree pour I'appareil non HAVi. 
ipAddressList est la liste des adresses IP de I'appareil non HAVi. 

Lorsqu'un appareil HAVi du reseau souhaite interagir avec un 
appareil non HAVi sur le reseau (LAV pour « Legacy Audio Video device ») i| 
peut installer un module de controle d'appareil (DCM) capable de gerer cette 
interaction. Pour ('identification de cet appareil dans le monde HAVi il est 
necessaire de lui attribuer un GUID sachant qu'un appareil non-HAVi ne 
possede pas un tel identificateur. L'appareil HAVi souhaitant agir avec lui va 
done lui attribuer un GUID et va servir de relais dans le monde HAVi pour cet 
appareil adresse par ce GUID (proxy en anglais). La creation de ce GUID 
relais va etre signalee sur le reseau par cet evenement, non local, signalant 
le GUID relais cree et les adresses IP de I'appareil ainsi identifie. 
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Le module CMMIP, ainsi implements, permet done de construire la 
liste des GUID des appareils du reseau et de faire le lien entre les GUID et 
les adresses IP de ces appareils. II permet aussi d'envoyer des messages IP 
sur le reseau a un appareil connu par son GUID ou son adresse IP. II offre 
5 egalement la possibility de s'inscrire pour recevoir des messages IP 
caracterises par leur origine et le protocole utilise au-dessus de IP. 

Un appareil 6.1 capable de supporte HAVi sur un reseau IP possede 
une architecture decrite dans la figure 6. II doit posseder un bus interne 6.4 
10 reliant un processeur 6.2 qui va executer les modules decrits de la pile HAVi. 
Ces programmes stockes dans la m6moire morte 6.3 de I'appareil vont se 
charger dans la memoire vive 6.5 pour Texecution. Les echanges avec le 
r6seau IP 6.7 vont se faire via ('interface reseau IP 6.6. 

15 

■ 



•« • • 



1 er depot 

20 



REVENDICATIONS 
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1. Methode de decouverte, par un appareil connectable a un reseau 
5 de communication, des autres appareils connectes a ce reseau caracterisee 
en ce qu'elle comporte les etapes suivantes : 

- connexion de I'appareil audit reseau ; 

- envoi d*uh message d'annonce contenant des 
informations d'auto description decrivant I'appareil a 
destination de tous les autres appareils connectes a ce 
reseau ; 

- envoi d'un message de demande d'informations d'auto 
description a tous les autres appareils connectes a ce 
reseau ; 

- reception d'un message de reponse de chacun des 
autres appareils du reseau contenant les informations 
d'auto description de cet autre appareil. 

2. Methode selon la revendication 1 ou le message de demande et le 
20 message d'annonce sont confondus. 

3. Methode selon I'une des revendications 1 ou 2 ou les informations 
d'auto description decrivant un appareil contiennent I'adresse sur le reseau 
de I'appareil. 



15 



25 



30 



4. Methode selon I'une des revendications 1 a 3 oO les informations 
d'auto description decrivant un appareil contiennent un identificateur global 
unique, different de I'adresse, identifiant I'appareil sur le reseau. 

5. Methode selon I'une des revendications 1 a 4 ou les informations 
d'auto description decrivant un appareil contiennent les caracteristiques d'un 
module logiciel permettant de controler cet appareil. 
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6. M6thode seloh Tune des revendications 1 a 5 ou le message 
d'annonce est envoye en diffusion generate sur le reseau. 

5 7. Methode selon Tune des revendications 1 a 5 ou le message 

d'annonce est envoys en diffusion multipoint sur une adresse de diffusion 
multipoint predefinie a laquelle les autres appareils doivent §tre abonn§s. 

8. Appareil connectable a un reseau caracterise en ce qu'il possede 
10 des moyens d'envoyer un message d'annonce, contenant des informations 

d'auto description le decrivant, & tous les autres appareils du reseau, des 
moyens d'envoi d'un message de demande d'informations d'auto description 
& tous les autres appareils du reseau et des moyens de reception des 
messages de rdponses contenant des informations decrivant chacun des 
15 autres appareils du r§seau. 

■ 

9. Appareil selon la revendication 8 ou les informations d'aato 
description d6crivant un appareil contiennent I'adresse sur le reseau de 
1'appareil. V 

20 

10. Appareil selon Tune des revendications 8 a 9 qui comporte des 
moyens permettant de generer un identificateur global unique, different de 
I'adresse de I'appareil, sur le reseau. 

25 11. Appareil selon Tune des revendications 8 a 10 ou les 

informations d'auto description decrivant un appareil contiennent les 
caracteristiques d'un module logiciel permettant de controler cet appareil. 

12. Appareil selon Tune des revendications 8 a 11 qui comporte des 
30 moyens d'envoi du message d'annonce en diffusion generate sur le reseau. 
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13. Appareil selon Tune des revendications 8 a 11 qui comports des 
moyens d'envoi du message d'annonce en diffusion multipoint sur une 
adresse de diffusion multipoint pred6finie a laquelle les autres appareils 
doivent etre abonnes. 
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